Secure Socket Layer Virtual Private Network (SSL VPN) is a Virtual Private Network (VPN) technology which implements remote access by using a Secure Socket Layer (SSL) encryption connection. FIGS. 1A and 1B show diagrams illustrating network structures of the SSL VPN. As shown in FIG. 1A, an SSL connection is established between a remote host and an SSL VPN gateway, and packets are transmitted on the Internet in an encryption mode. The SSL VPN gateway terminates the SSL connection, transmits a request from the remote host in a plain language mode through a Transmission Control Protocol (TCP) connection established between the SSL VPN gateway and a VPN resource server of an inner network or through direct IP forwarding, and transmits a response of a server to the remote host through the SSL connection
Remote access modes of users include a TCP access mode, a WEB access mode and an IP access mode. Remote access processes of the TCP access mode and the WEB access mode are the same, while are a little different from a remote access process of the IP access mode. Specifically, in the TCP/WEB (“/” indicates “or”) access mode, the remote access process includes the following steps.
Step A, a user1 performs information interaction with an SSL VPN gateway, and establishes a connection related to a remote access. Step A specifically includes the following.
a1: through a remote host, the user1 requests the SSL VPN gateway to perform logon and authentication; the SSL VPN gateway returns a user resource page to the user1 after the used passes the logon and authentication, and the user resource page includes VPN resource information that the used is allowed to access.
a2: through the remote host, the user1 establishes an SSL connection with the SSL VPN gateway when requesting accessing a VPN resource; in the TCP/WEB access mode, the gateway needs to maintain a bidirectional connection relation table, i.e. the SSL connection between the SSL VPN gateway and the user host and a TCP connection between the SSL VPN gateway and a VPN resource server; hence, the used sends a user identity (ID) and an ID of the VPN resource requested to be accessed to the SSL VPN gateway through the SSL connection established. The user ID is used to identify a user, and the ID of the VPN resource is used to indicate the resource requested to be accessed.
a3: according to the ID of the VPN resource, the SSL VPN gateway establishes and maintains the TCP connection between the SSL VPN gateway and a VPN resource server 1 to which the VPN resource requested to be accessed belongs for the user1. Two ends of the TCP connection established for the used are: a private network address of a physical exit interface on the SSL VPN gateway, 172.1.1.1, and a private network address of the VPN resource server 1, 10.3.1.1.
Step B, after the connection related to the remote access is established, the user1 sends a packet to the SSL VPN gateway through the SSL connection, and the SSL VPN gateway sends the packet received through the SSL connection to the VPN resource server 1 through the TCP connection established for the user1.
In the TCP/WEB access mode, the user1 does not need to know the address of the VPN resource server, thus the packet sent from the user1 to the SSL VPN gateway merely carries a public network IP header. In the packet sent by the user1, such as packet {circle around (1)} shown in FIG. 1A, a public network source address in the public network IP header is a public network address of a remote host used by the user1, 60.191.123.24, and a public network destination address in the public network IP header is a public network address of the SSL VPN gateway, 220.189.204.90.
The core component of the SSL VPN gateway is an SSL VPN service unit. The SSL VPN service unit includes three modules, a TCP access mode processing module, a WEB access mode processing module and an IP access mode processing module. Packet forwarding procedures of the TCP access mode processing module and the WEB access mode processing module are similar, and thus the above two modules may be deemed as one module, i.e. a TCP/WEB access mode processing module. The TCP/WEB access mode processing module operates on an application layer, while the IP access mode processing module operates on both the application layer and an IP layer.
In the TCP/WEB access mode, the forwarding process in step B includes sub-steps b1˜b3.
b1: after the packet enters the SSL VPN gateway through the SSL connection, the IP layer removes the public network IP header and sends the data part of the packet to the TCP/WEB access mode processing module located on the application layer via a TCP layer;
b2: the TCP/WEB access mode processing module determines to forward the received packet through the TCP connection established for the user1 according to the bidirectional connection relation table; in this case, the packet is sent to the TCP layer;
b3: the TCP layer adds a private network IP header to the packet according to the TCP connection established for the user1 (172.1.1.1 to 10.3.1.1), and sends the packet to the IP layer; where a private network source address and a private network destination address in the private network IP header are 172.1.1.1 and 10.3.1.1 respectively;
b4: the IP layer performs route searching according to a destination address of the packet, and then forwards the packet via the physical exit interface 172.1.1.1. In the forwarded packet, such as a packet {circle around (2)} shown in FIG. 1A, the private network source address and the private network destination address in the private network IP header are 172.1.1.1 and 10.3.1.1 respectively.
Step C, the SSL VPN gateway receives a response packet returned by the VPN resource server 1 through the TCP connection, and returns the response packet to the user1 through the SSL connection. This step equals to a reverse operation of the step B. First, the IP layer removes the private network IP header of the response packet and sends the response packet to the TCP/WEB access mode processing module through the TCP layer, and the TCP/WEB access mode processing module determines to return the response packet through the SSL connection between the user1 and the TCP/WEB access mode processing module. Then, the TCP layer adds a public network IP header to the response packet. And finally, the IP layer performs the route searching and forwards the response packet.
Thus, the remote access in the TCP/WEB access mode is finished.
When the user1 performs the remote access in the IP access mode, an address pool used for allocating addresses for users needs to be established. The access process still includes the above steps A, B and C, but specific implementation of each step is different.
In step A, the SSL VPN gateway, besides returning the user resource page, also needs to randomly select one IP address from the address pool and allocate the IP address to the user1 as a source address, i.e. a virtual address used by the user1 when accessing the VPN resource server. It is supposed that the virtual address is 10.1.1.2. When the user1 needs to access the VPN resource, only the SSL connection rather than the TCP connection is established. However, the SSL VPN gateway needs to maintain a relation table of the users, the virtual addresses and the SSL connections, but does not need to know the VPN resource server to be accessed by the user1. Therefore, during the information interaction with the SSL VPN gateway, the user1 only needs to send the user ID to the SSL VPN gateway through the SSL connection established.
In step B, the user1 still sends the packet to the SSL VPN gateway through the SSL connection, and the packet includes not only the public network IP header as described above, but also a private network IP header. In the packet sent by the user1, such as a packet {circle around (1)} shown in FIG. 1B, the public network IP header of the packet {circle around (1)} is the same as that shown in FIG. 1A, a private network source address is the virtual address of the user1, 10.1.1.2, and a private network destination address is a private network address of the VPN resource server to be accessed, 10.3.1.1. The private network address of the VPN resource server may be obtained by the user1 in advance.
When the SSL VPN gateway receives the packet, the IP layer removes the public network IP header, and sends the packet to the IP access mode processing module through the TCP layer. The IP access mode processing module determines to transmit the packet directly according to the private network IP header. The packet without the public network IP header may be a packet {circle around (2)} as shown in FIG. 1B.
In step C, the SSL VPN gateway receives a response packet returned by the VPN resource server 1; the IP access mode processing mode determines to return the response packet through the SSL connection between the IP access mode processing mode and the user1 according to the relation table of the users, the virtual addresses and the SSL connections; and then the TCP layer adds a public network IP header to the response packet, and the IP layer performs the route searching and forwards the response packet to the user1.
Thus, the remote access in the IP access mode is finished.
MPLS L3VPN is a Layer 3 (L3) VPN technology based on a Provider Edge (PE) router in VPN solutions of service providers. MPLS L3VPN issues VPN routes in an MPLS network by using a Border Gateway Protocol (BGP), forwards an MPLS packet in the MPLS network by using label forwarding. FIG. 2 is a schematic diagram illustrating a conventional network structure of an MPLS L3VPN. As shown in FIG. 2, the MPLS L3VPN model consists of the following three parts.
A Customer Edge (CE) device, called CE for short, has an interface directly connecting with a Provider Edge (PE) router. The CE may be a router, an exchanger or a host. The CE can not “apperceive” existence of the VPN and does not need to support the MPLS.
A PE router, called PE for short, is an edge device of the MPLS network, and directly connects with the CE. In the MPLS network, all processing of VPN information is maintained in the PE. VPN Routing & Forwarding Instances, called VPN instances, are stored in the PE. A routing forwarding table and an MPLS label forwarding table are included in the VPN instance. The routing forwarding table includes two kinds of routes, one is for indicating an exit interface through which a packet from the CE is to be forwarded, and the other is for indicating an exit interface through which a packet from the P router is to be forwarded. The MPLS label forwarding table includes two kinds of table entries, one is a VPN label (inner layer label) of each VPN, and the other is a forwarding entry, i.e. for indicating next hop P router information and an MPLS forwarding label for a packet from the CE.
The P router, called P for short, is a backbone router of the MPLS network, does not directly connect with the CE, only needs to have basic MPLS forwarding capability and does not need to maintain VPN information.
As shown in FIG. 2, different physical interfaces of the PE router connect with different CE devices, one physical interface is bound with one VPN, and a VPN instance of the VPN is formed according to the physical interface bound with the VPN. When a packet from a CE device enters through a certain physical interface of the PE, the PE router determines a VPN to which the packet belongs according to the physical interface, and forwards the packet by using the VPN instance of the VPN to which the packet belongs. The forwarding processing includes: searching for an exit interface of the packet according to a routing forwarding table, and searching for a VPN label (inner layer label), an MPLS forwarding label (outer layer label), next hop P device information and the like according to the MPLS label forwarding table; adding a VPN label and an MPLS label to the packet according to the found information, and forwarding the packet. When receiving a packet from the P router, the PE router searches for a VPN instance according to the VPN label contained in the packet, and forwards the packet to the CE device through a physical interface bound with the VPN instance. Conventionally, the PE router may also differentiate different VPN users according to Virtual Local Area Network (VLAN) access information.
When a local area network connecting with the SSL VPN gateway in FIGS. 1A and 1B adopts the MPLS L3VPN, it is urgently to solve the following problems: how to connect the SSL VPN gateway with a device in the MPLS L3VPN, how to forward a packet received through the SSL connection to the MPLS network so as to make a remote user remotely access a VPN resource server in the MPLS VPN through the SSL connection. However, there is no solution for those problems currently.